home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / ospf / ospf-minutes-92nov.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.7 KB  |  162 lines

  1. Editor's Note: 11/23/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by John Moy/Proteon
  7.  
  8. Minutes of the Open Shortest Path First IGP Working Group (OSPF)
  9.  
  10. The OSPF Working Group met at the November 1992 IETF in Washington, D.C.
  11.  
  12. The meeting began with some administrative details.  For those that had
  13. missed the announcement, it was mentioned that RFCs 1370/1371 had been
  14. published, officially making OSPF the recommended IGP for the TCP/IP
  15. Internet.  Next, an informal poll was taken concerning attendance at
  16. next year's Amsterdam IETF. Based on that poll, the OSPF Working Group
  17. will probably not meet at that IETF. Lastly, there was some discussion
  18. of maintenance of the OSPF mailing list (trantor.umd.edu needs a
  19. forwarding record for ospf-request).
  20.  
  21. The last call for comments was started on four documents.  These
  22. documents have been stable for a number of months, and we hope to have
  23. them issued as RFCs before the next IETF (the latest versions of all of
  24. them had been issued as Internet-Drafts before the meeting):
  25.  
  26.  
  27.    o The OSPF V2 specification.  Two changes have been made since the
  28.      last meeting.  First, the definition of the Link State ID in type 3
  29.      and 5 LSAs has been relaxed to support CIDR (supernetting),
  30.      allowing one or more of the Link State IDs host bits to be set.
  31.      Since this will soon be an operational issue, vendors were
  32.      encouraged to modify their implementations accordingly as soon as
  33.      possible.  It was decided to make the default route a special case,
  34.      requiring both its mask and its Link State ID to be 0.0.0.0.  The
  35.      other change to the spec was a reminder not to set the ``AS
  36.      boundary router'' bit in router-LSAs for stub areas.
  37.    o The OSPF MIB. Changes had been made to allow host routes to be
  38.      deleted, and to support the new NSSA and multicast routing options.
  39.      At the meeting, it was decided to clear up the definition of the
  40.      ospfAreaLsaCksumSum object, making it clear that it included
  41.      optional LSAs (like the group-membership-LSA) and therefore was not
  42.      necessarily the same for all routers in an area.  Also, to better
  43.      support supernetting, it was decided to include a network mask in
  44.      the Link State Database and External Link State Database tables.
  45.    o The NSSA option.  At the meeting it was decided to change the
  46.      document to allow summarization of type 7 LSAs into a single type 5
  47.      LSA at NSSA boundaries.
  48.    o The OSPF Trap MIB. This document has remained unchanged since the
  49.      last meeting.
  50.  
  51.  
  52. A number of issues were brought up by Robert Ching, on behalf of the
  53. OSPF Forum.  Most were just requests for technical clarification
  54. (addressed in the meeting, but omitted from these notes in the interest
  55. of brevity).  There was desire for an OSPF/RIP transition document (any
  56. volunteers?).  Also, there was some confusion over the way OSPF
  57.  
  58.                                    1
  59.  
  60.  
  61.  
  62.  
  63.  
  64. represented serial lines.  As John Moy explained, they are represented
  65. in router-LSAs as a direct connection to a neighbor, with each
  66. neighboring router advertising the other's serial line address as a
  67. (stub) host route.  This encourages pings to a serial line address to
  68. actually traverse the serial line.  However, two other representations
  69. are also possible:  each neighboring router advertising its own address
  70. as a host route, or each neighboring router advertising a stub route to
  71. a subnet that has been allocated to the serial line.  It was pointed out
  72. that the latter representation had the problem that traffic addressed to
  73. a non- existent host on the serial line had a tendency to loop until its
  74. TTL expired.
  75.  
  76. Osmund deSouza outlined a proposed usage document for OSPF over Frame
  77. relay.  Requiring no protocol changes, this document would allow a Frame
  78. relay network to be configured as an arbitrary collection of NBMA
  79. networks, numbered and unnumbered serial lines.
  80.  
  81. Tom Pusateri presented his document on running IP multicast over 802.5
  82. networks.  A functional address (03-00-00-20-00-00) has been allocated,
  83. and Tom's document mandates that the token-ring address be configurable
  84. as either the all-ones broadcast MAC address (current practice), the new
  85. functional address or a group address (for possible future definition
  86. when token ring controller support is available).  This document should
  87. soon be published as an RFC.
  88.  
  89. John Moy led a discussion of his proposal for how to deal with OSPF
  90. database overflow.  It was decided to:
  91.  
  92.  
  93.   1. Exempt default routes from the limit calculation.
  94.  
  95.   2. Automatically regenerate routes that have been earlier flushed due
  96.      to database overflow (this regeneration will be done after some
  97.      random interval between 1 minute and a configurable upper bound,
  98.      with an option to completely disable the regeneration) and,
  99.  
  100.   3. Set the LSA limit (which must be the same through all routers)
  101.      through SNMP. Hopefully we will have a document describing this in
  102.      detail next meeting.
  103.  
  104.  
  105. At the end of the meeting, mention was made of two possible new work
  106. items:
  107.  
  108.  
  109.   1. A scheme to use the OSPF tag field and a new LSA type to replace
  110.      IBGP and,
  111.   2. A new authentication type using something like MD5.  These are
  112.      possible subjects for the next meeting.
  113.  
  114.  
  115. Attendees
  116.  
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Fred Baker               fbaker@acc.com
  125. Ken Benstead             kbenstead@coral.com
  126. Jeffrey Burgan           jeff@nsipo.nasa.gov
  127. Dean Cheng               dean@sun2.retix.com
  128. Robert Ching             rching@nat.com
  129. Rob Coltun               rcoltun@ni.umd.edu
  130. Osmund de Souza          osmund.desouza@att.com
  131. Vince Fuller             vaf@stanford.edu
  132. William Haggerty         haggerty@ctron.com
  133. Jonathan Hsu             brenda@penril.com
  134. Akira Kato               kato@wide.sfc.keio.ac.jp
  135. David LeRoy              dleroy@mitchell.cit.cornell.edu
  136. Tony Li                  tli@cisco.com
  137. Olli-Pekka Lintula       olli-pekka.lintula@ntc.nokia.com
  138. Robin Littlefield        rlittlef@wellfleet.com
  139. Kent Malave              kent@bach.austin.ibm.com
  140. Jun Matsukata            jm@eng.isas.ac.jp
  141. David Meyer              meyer@oregon.uoregon.edu
  142. Douglas Miller           dmm@telebit.com
  143. John Moy                 jmoy@proteon.com
  144. Julianne Myers           jmyers@network.com
  145. Laura Pate               pate@gateway.mitre.org
  146. Thomas Pusateri          pusateri@cs.duke.edu
  147. Manoel Rodrigues         manoel_rodrigues@att.com
  148. Paul Serice              serice@cos.com
  149. Erik Sherk               sherk@sura.net
  150. Roy Spitzer              roy.spitzer@sprint.com
  151. John Tavs                tavs@vnet.ibm.com
  152. Paul Traina              pst@cisco.com
  153. Iain Wacey               cat@pluto.dss.com
  154. James Watt               james@newbridge.com
  155. Luanne Waul              luanne@wwtc.timeplex.com
  156. Douglas Williams         dougw@ralvmg.vnet.ibm.com
  157. Linda Winkler            lwinkler@anl.gov
  158.  
  159.  
  160.  
  161.                                    3
  162.